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(54) Public-key-encryption data-communication system and data-communication-system 
forming method 



(57) A public-l<ey-encryption data-communication 
system Includes a pubiic-key-certificate issuer authority. 
The publicrkeyHcertlficate Issuer authority performs the 
issuanceof a public key certificate and management op- 
erations, certification of a subject to be certificated, 
which is a certificate issuing request, and management- 
such as registration processing are executed by a root 
registration authority or each registration authority. The 
public-key-certificate issuer authority performs process- 
ing for validating, invalidating, and deleting the certifi- 
cate in accordance with a request from the root regis- 
tration authority. The/ppt registr ation a uthoritV-accepts^ 
a request for issuing a public key certif teate conrespond- 
ing to the subject to be certificated which is under the 
control of a certrfteated registration authority, and trans- 
fers it to the public-key-certificate issuer authority in a 
fonn in which a signature Is added to It. Processes by 
the publlc-key-certlfk:ate issuer authority, the root reg- 
istration authority, the registration authority are separat- 
ed, whereby the need for new implementation of user 
recognition, certificate issuance, registration, and man- 
agement is eliminated. 
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Description 

BACKGROUND OF THE INVEhfTION 

1. Field of the Invention 5 

[0001] The present invention relates to public-key- 
certificate issuing systems for proving the validity of a 
public key for use in encrypted data transmission in elec- 
trons distn*biition systems, and data communication 
methods. In particular, the present invention relates to 
a pubric-key-certificate issuing system in which a data- 
transmission-servbe entity enables a publk: key and a 
public-key certificate to be used for general purposes 
without having a certificate authority function for issuing 
a public-key certificate, and to a data communication 
method. 

2. Description of the Related Art 

[0002] Nowadays, various types of sofhware data 
(hereinafter referred to as "contents"), such as game 
programs, audio data, image data, and document-mak- 
ing programs, are distributed via networlcs such as the 
Internet Also, the purchase and sale of goods via a net- 
work, such as online shopping, has become gradually 
popular. 

[0003] In data communication of the above network 
type, in general, a data transmitting side and a data're- 
ceiving side transfer necessary data to each other after 
verifying that each side is correct, In other words, a data 
transfer system in which security is taken Into consider- 
ation is formed. In a technique for realizing a security 
system in data transfer, encryption processing on data 
to be transferred and sign processing on data are per- 
formed. 

[0004] By decryption processing based on a prede- 
termined procedure, encrypted data can be restored to 
decrypted data (plaintext) that is usable. Data encryp- 
tion and decryption have been well known in which an 
encryption key is used in encryption processing on the 
information and a decryption key is used in decryption 
processing. 

[0005] There are various types of data encryption and 
decryption using encryption and decryption keys. One 
example of the types is a so-called "public key encryp- 
tion". In the public key encryption, by using different keys 
for a transmitter and a receiver, one key is used as a 
public key that can be used by unspecified users, and 
the other key is used as a private key that is kept secret. 
For example, a data encryption key is used as a public 
key, and a decryption key is used as a private key. Oth- 
erwise, the public key encryption is used in a form that 
uses a certificator generating key as a private key and 
a certificator decrypting key as a public key. 
[0006] The public key encryption is advantageous to 
the management of keys since it differs from a so-called 
"symmetric-key encryption method" using a symmetric 



key for decryption in that a particular person needs to 
have a private key that must be kept secret. However, 
since the symmetric-key encryption method has a slow- 
er data processing speed than that of the public key en- 
cryption, it is often used for small-data-amount objects 
such as a private key delivery, and digital signing. One 
typical example of the publk: key encryption is RSA 
(Rivest-Shamir-Aldleman) encryption. This uses the 
product of very large prime numbers (e.g., 150 digits), 
and uses difficulty of factorization processing on the 
product of the two large prime numbers. 
[0007] In the public key encryption, a technique is of- 
ten used which is designed allowing the general public 
to use a publk^ key and whbh uses a public-key certifi- 
cate certificating ttie validity of a distributed public key 
For example, User A generates a pair of a public key 
and a private key, sends the generated public key to a 
certificate authority, and obtains a public-key certificate 
from the certificate authority. User A opens the publb- 
key certificate to the public. By obtaining the public key 
from the publk:-key certificate by perfomning a predeter- 
mined procedure, an unspecified user encrypts a docu- 
ment or the like, and sends It to User A. User A is a 
system that uses the private key to decrypt the encrypt- 
ed document. User A is also a system that puts a sig- 
nature on the document by using the private key and 
that verifies the signature by obtaining the public key 
from the publk^-key certificate through a predetermined 
procedure. 

[0008] The publc-key certificate is described with ref- 
erence to Fig. 1 . The public-key certif teate is a certif teate 
issued by a certificate authority or an issuer authority, 
and Is a certificate made such that, by submitting from 
a user the user's ID, a public key, etc., to the certificate 
authority, the certiftoate authority adds infomiation such 
as the ID of the certificate authority and a revocation 
date and also puts a certificate authorit/s signature. 
[0009] The public-key certificate shown in Fig. 1 in- 
cludes a certificate version number, a certifbate serial 
number assigned to a certificate user by the certiftoate 
authority, algorithm and parameters used for electronb 
signing, a certificate authority name, a certificate revo- 
cation date, a certificate user name (user ID), a pubib 
key for the certificate user, and an electronic signature 
of the certificate user 

[0010] The electronic signature Is data generated by 
generating a hash value by applying a hash function to 
the entirety of the certificate version number, the certif- 
teate serial number assigned to the certificate user by 
the certificate authority, the algorithm and parameters 
used for electronic signing, the certificate authority 
name, the certificate revocation date, the certif k:ate user 
name, the entirety of the public key of the certificate us- 
er, and the electronic signature, and using a certificate- 
authority private key on the hash value. 
[0011] The certificate authority issues the publrc key 
certificate shown in Fig. 1 , updates the public-key cer- 
tifk^ate that has expired, and performs the generation. 
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management, and distribution (these are caited "revo- 
cation") of an unauthorized person list for expelling us- 
ers who have taken unauthorized conducts. The certif- 
icate authority also generates a public key and a private 
key. as required. 

[0012] When using the public-key certifk»te, a user 
uses the certificate authority public key retained by the 
user to verify the electronic signature on the public-key 
certificate, extracts the public key from the public-key 
certificate after succeeding in the verif Nation of the elec- 
trons signature, and uses the publk; key. Accordingly, 
all users who use the public-key certificate must retain 
certificate-authority publte keys that are common. 
[0013] In a data transmission system based on the 
above-described public key encryption using a public- 
key certificate issued by a certificate authority, If a dif- 
ferent pubib key is used, It is required to newly request 
a certificate authority to issue a public-key certifteate 
corresponding to the public key. or it is required to con- 
struct a certlfteation system having a certificate authority 
functbn. In other words, for example, when a service 
provider that distributes contents or offers a goods pro- 
viding service starts a new servtee (new electronic dis- 
tribution system) and starts to use a new public key, the 
servtoe provider always must request a certificate au- 
thority to perform the issuance and management of a 
public-key certifk^te corresponding to the new public 
key or to construct a certificating system having a cer- 
tificate authority system, so that problems occur in that 
a lot of costs and time are required. In addition, when 
certif bates Issued by different certificate authorities are 
used to perform communication, it is required, for veri- 
fying issuance authority signatures in the certificates, 
that a signature verifying key be acquired by establish- 
ing a link to a center, and this case Is not suitable for 
offline use. 

SUIWII^ARY OF THE INVENTION 

[001 4] Accordingly, it is an object of the present inven- 
tion to provide a publto-key-encryption data-communi- 
cation system and data-communication method that 
simplify a public-key-certificate issuing system and that 
enable a servbe provider to easily use a publb-key cer- 
tificate when a service provider starts a new service. 
[0015] To this end, according to an aspect of the 
present invention, the foregoing object is achieved 
through provision of a public-key-encryption data-com- 
'munbatlon system Including a j^ublic-key -gfir^^*^ 
suer authority for issuing a publto key certtf bate core- 
spondingto a subject to be c ertificated which perfomriing 
^ata transfer using public'ke y encryptio n, a root regis- 
tration authority wiiich exec utes mutual Jata transfe r 
with the publlc-key-certificate is suer autho rity, which 
performs certification ofthe subject when the subject is 
under the control of th e TobU egist ration authority and 
whbh requests the publjc-key-certificate i ssuer autf ior- 
ity to issue the public key certificat e corresponding to 



the subject, and a registration authority whbh executes 
mutual data transfer with the root registration authority, 
which perfonns certification of the subject when the sub- 
ject is under the control of the registratiori authority and 

5 wfiEh requestelhe root registration "authorit y to is sue 
the public key certifi citircbnnespohding to the subject.^ 
[0016] preTerat)i y,nn'th^ubnc-key-'unUiyp tf ^ ^ 
communication system, the root registration authority 
treats a plurality of registration authorities as subjects 

10 to be certificated, and each of the plurality of registration 
authorities treats, as a subject to be certificated, one of 
at least one service provider, at least one user temninal, 
and at least one user which are under the control of the 
registration authority. 

15 [0017] In the publlc-key-encryptton data-communica- 
tion system, the registratbn authority or at least one 
service provider which is under the control of the regis- 
tration authority may apply, to a plurality of different serv- 
ices, a public key certif bate corresponding to a subject 

20 to be certifbated whbh is under the control of the reg- 
istration authority or of the at least one service provider 
which is under the control of the registration authority. 
[0018] In the pubtic-key-encryption data-communica- 
tion system, the root registration authority may include, 

25 as one of a plurality of registration authorities as sub- 
jects to be certificated whbh are under the control of the 
root registration authority, a clearing center for execut- 
ing settlement processing, and in processing using a 
public key certificate which Is Issued via the clearing 

30 center, settlement may be perf onned which relates to a 
service provided by a registration authority other than 
the clearing center which Is under the control of the root 
registration authority or by at least one service provider 
which is under the control of the registration authority 

3s other than the clearing center. 

[001 9] In the public-key-encryptlon data-communica- 
tion system, the publb-key-certificate Issuer authority 
may hold a list of the correspondence among pubib 
keys and corresponding pubIb key certificates, and the 

40 identifiers of subjects to be certificated for which the 
public key certificates are issued, and either the root reg- 
istration authority or the registration authority may hold 
entity data which con^espond to the subjects and whbh 
include certification data on the subjects. 
[0020] In the public-key-encryption data-communica- 
tion system, the public key certif bates may each include 
an electronic signature field for an electronic signature 
of the publlc-key-certifbate issuer authority, and a plu- 
rality of algorithms may be used as a signature algorithm 

50 for the electronic signature generated in the electronic 
signature field, and the public key certificates may each 
include a field identifying the used algorithm. 
[0021 ] In the public-key-encryptbn data-communica- 
tion system, in data transfer between the publb-key-cer- 

55 tifbate Issuer authority and the root registration author- 
ity, cross certification processing may be perfonned, 
and when the cross certification is established, mutual 
data transfer may be executed . In data transfer between 
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the root registration authority and the registration au- 
thority, cross certification processing may be performed, 
and when the cross certification is established, mutual 
data transfer may be executed, and in data transfer be- 
tween the registration authority and the subject, cross 
certification processing may be performed, and when 
the cross certification is established, mutual data trans- 
fer may be executed. 

[0022] In the public-key-encryption data-communica- 
tion system, between two among the public-key-certifi- 
cate Issuer authority, the root registration authority, the 
registration authority, and the subject, data may be 
transferred In a form In which the data Includes a gen- 
erated electronic signature of a data transmitting side. 
[0023] Preferably, in the public-key-encryption data- 
communication system, at least one of the root registra- 
tion authority and the registration authority possesses a 
revocation list conceming public key certificates con-e- 
sponding to subjects which are under the control of the 
at least one, executes the updating of the revocation list, 
and requests the public-key-certificate Issuer authority 
to perfomi data processing corresponding to the updat- 
ing, 

[0024] In the public-key-encryption data-communk:a- 
tlon system, at least one of the root registration authority 
and the registration authority may request the Issuance 
of a plurality of pubic key certlfk:ates comespondlng to 
a plurality of servtoes whbh are under the control of the 
one authority. 

[0025] In the publb-key-encryption data-commun Mo- 
tion system, the- public key certificate may Include a 
common electronic signature of the public-key-certifi- 
cate Issuer authority which Issues the public key certif- 
icate, and one of a root registration authority, a registra- 
tion authority, a servtee provider, and a user device 
whbh perform processing for the vefif k:ation of one pub- 
\\c key certificate issued by the public-key-certificate Is- 
suer authority may perfomn offline processing for the 
verification of different public key certificates Issued by 
a single publk>key-certiftoate issuer authority. 
[0026] In the public-key-encryption data-communtea- 
tion system, the registration authority may be formed as 
a system holder as an authority which provides or man- 
ages a distribution infrastructure for contents whbh are 
usable by a user tenminal, contents for use in providing 
a sen/ice, or a service, and the system holder may con- 
trol and may treat a service provider and the user termi- 
nal as subjects to be certificated. 
[0027] Preferably, in the publk)-key-encryption data- 
communication system, the root registration authority 
controls a plurality of system holders which provide or 
manage an infrastructure for distributing different con- 
tents or sen/ices, receives a public-key-certificate issu- 
ing request via one of the system holders from one of at 
least one service provider and at least one user terminal 
which are under the control of the one system holder, 
and requests the public-key-certificate issuer authority 
to issue a public key certificate. 



[0028] In the public-key-encryption data-communica- 
tion system, under the control of the system holder, the 
system holder may have contents creator which per- 
forms provision of contents by using a distribution infra- 

5 structure for contents or a sen^ice provided or managed 
by the system holder, and the system holder may treat 
the contents creator as a subject to be certificated. 
[0029] Preferably, in the publrc-key-encryption data- 
communtoatlon system, a user devtee which Is under the 

10 control of a plurality of different system holders control- 
led by a common public-key-certificate issuer authority 
has a public key of the common publto-key-certtficate 
Issuer authority. i 
[0030] According to another aspect of the present in- 

15 vention, the foregoing object Is achieved through provi- 
sion of a pubiic-key-encryption data-communk»tion- 
system fomnlng method Including the steps of request- 
ing, by a subject to be certificated, a registration author- 
ity to issue a public key certif bate, transferring, from the 

20 registration authority to a root registration authority cer- 
tifteatlng the registration authority, a publlc-key-certlfl- 
cate issuing request from the subject, and transferring, 
from the root registration authority to a publte-key-cer- 
tifcate issuer authority certificating the root registration 

25 authority, the public-key-certificate issuing request from 
the subject. 

[0031] Preferably, in the publte-key-encryptlon data- 
communication-system fomning method, the root regis- 
tration authority treats a plurality of registration author- 

30 Ities as subjects to be certif bated, and each of the plu- 
rality of registration authorities treats, as a subject to be 
certificated, one of at least one service provider, at least 
one user terminal, and at least one user which are under 
the control of the registration authority. 

35 [0032] In the publlc-key-encryptlon data-communica- 
tion-system fonning method, the registration authority 
or at least one servce provider which Is under the con- 
trol of the registration authority may apply, to a plurality 
of different servbes, a public key certificate correspond- 

40 ing to a subject to be certif bated which is under the con- 
trol of the registration authority or of the at least one 
sen/Ice provider which is under the control of the regis- 
tration authority. 

[0033] In the publlc-key-encryptbn data-communica- 
45 tion-system fomnlng method, the root registration au- 
thority may include, as one of a plurality of registration 
authorities as subjects to be certificated which are under 
the control of the root registration authority, a clearing 
center for executing settlement processing, and In 
50 processing using a public key certificate which Is issued 
via the clearing center, settlement may be perfonned 
which relates to a servbe provided by a registration au- 
thority other than the clearing center whbh is under the 
control of the root registration authority or by at least one 
55 service provider which is under the control of the regis- 
tration authority other than the clearing center. 
[0034] In the publlc-key-encryptlon data-connmunica- 
tion-system forming method, the publb-key-certlfbate 
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issuer authority may hold a list of the correspondence 
among public keys and con-esponding public key certif- 
icates, and the Identifiers of subjects to be certificated 
for which the publk: key certificates are issued, and ei- 
ther the root registration authority or the registration au- 5 
thority may hold entity data which correspond to the sub- 
jects and whbh Include certification data on the sub- 
jects. 

[0035] In the pubtk:-key-encryption data-communba- 
tion-system forming method, the public key certificates io 
may each Include an electronic signature field for an 
electronic signature of the public-key-certificate issuer 
authority, and a plurality of algorithms may be used as 
a signature algorithm for the electronic signature gener- 
ated In the electronic signature field, and the public key is 
certificates may each include a f iekl identifying the used 
algorithm. 

[0036] In the publte-key-encryption data-communtea- 
tion-system fomiing method, in data transfer between 
the public-key-K^rtifk^ate issuer authority and the root ^20 
registration authority, cross certif k:ation processing may 
be perfomried, and when the cross certification is estab- 
lished, mutual data transfer may be executed. In data 
transfer between the root registration authority and the 
registration authority, cross certif k:atlon processing may 25 
be performed, and when the cross certification is estab- 
lished, mutual data transfer may be executed, and in da- 
ta transfer between the registration authority and the 
subject, cross certification processing may be per- 
formed, and when the cross certif teatlon is established, so 
mutual data transfer may be executed. 
[0037] In the public-key-encryption data-communica- 
tion-system fomnlng method, between two among the 
public-key-certificate issuer authority, the root registra- 
tion authority, the registration authority, and the subject, 35 
data may be transferred in a form in which the data in- 
cludes a generated electrons signature of a data trans- 
mitting side. 

[0038] Preferably, In the public-key-encryption data- 
communication-system forming method, at least one of 40 
the root registration authority and the registration au- 
thority possesses a revocation list concerning publk: key 
certificates con^esponding to subjects whtoh are under 
the control of the at least one, executes the updating of 
the revocation list, and requests the publlc-key-certifi- ^ 
cate issuer authority to perform data processing corre- 
sponding to the updating. 

[0039] in the publk:-key-encryption data-communk:a- 
tion-system fomiing method, at least one of the root reg- 
istration authority and the registration aijthority may re- so 
quest the Issuance of a plurality of public key certif icates 
corresponding to a plurality of services which are under 
the control of the one authority. 
[0040] In the publb-key-encryptlon data-communtea- 
tion-system forming method, the public key certifbate ss 
may include a common electronic signature of the pub- 
Ite-key-certificate issuer authority which issues the pub- 
lb key certificate, and one of a root registration authority. 
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a registration authority, a servbe provider, and a user 
devce which perform processing for the verifbatlon of 
one public key certificate issued by the public-key-<:er- 
tificate issuer authority may perform offline processing 
for the verification of different pubib key certifbates is- 
sued by a single public-key-certrficate issuer authority. 
[0041] In the public-key^ncryption data-communica- 
tion-system fonming method, the registration authority 
may be f omried as a system holder as an authority whbh 
provides or manages a distribution infrastructure for 
contente which are usable by a user temnlnal, contents 
for use in providing a service, or a sen/ice, and the sys- 
tem holder may control and may treat a servbe provider 
and the user terminal as subjects to be certificated. 
[0042] Preferably, in the publb-key-encryption data- 
communbation-system forming method, the root regis- 
tration authority controls a plurality of system holders 
which provide or manage an infrastructure for distribut- 
ing different contents or sen^ices, receives a public-key- 
certificate issuing request via one of the system holders 
from one of at least one servbe provider and at least 
one user terminal which are under the control of the one 
system holder, and requests the publb-key-certificate 
issuer authority to issue a pubib key certificate. 
[0043] In the public-key-encryption data-communica- 
tion-system fomnlng method, under the control of the 
system holder, the system holder may have contents 
creator which performs provision of contents by using a 
distribution infrastructure for contents or a service pro- 
vided or managed by the system holder, and the system 
holder may treat the contents creator as a subject to be 
certificated. 

[0044] Preferably, in the publb-key-encryption data- 
communbation-system forming method, a user device 
which is under the control of a plurality of different sys- 
tem holders controlled by a common publb-key-certifi- 
cate issuer authority has a public key of the common 
public-key-certifbate issuer authority. 
[0045] The present Invention enables control of a root 
registration authority to perfomi certifbate acquiring 
processing that is conventionally perionmed by each 
service provider, and enables, for example, control of a 
clearing center (payment RA) to perfomn credit control 
processing (user's credit inquiry) with banking facilities 
such as banks, whbh Is executed for settiement caused 
by the distribution of contents, without controlling a pro- 
vider that performs contents distribution to perfomi the 
processing. In other words, a service provider that starts 
a new electronb distribution business can entrust the 
management of issuance of pubIb key certificates to the 
root registration authority and the a public-key-certifl- 
cate issuer authority, and can entrust settlement 
processing to anotiier registration authority which is un- 
der the control of the root registration authority, wherefc)y 
the servbe provider enables provision of service that us- 
es a user public key certificate by only performing user 
managing operations. 

[0046] Also the user managing operations can be en- 
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trusted to the root registration authority. A registration 
authority as a service provider can be designed to re- 
ceive user information, revocation infonnation, etc.» 
from the root registration authority, as required. 
[0047] In the present Invention, a pubtic-lcey-certifi- s 
cate issuer authority performs issuance of public key 
certificates and management operations, and userman- 
agement, such as processing of registering users who 
use public key certificates, is entrusted to a root regis- 
tration authority, whereby the need for executing user 
identifying operations dependent on service contents is 
eliminated. Also revocation list management is per- 
formed by the root registration authority, and the public- 
key-certificate issuer authority performs only processing 
for validating, invalidating, and deleting the certificate in 
accordance with a request from the root registration au- 
thority. 

[0048] As described above, in the present invention, 
processes by a publk:-key-cerfifk:ate issuer authority, a 
root registration authority, and a registration authority 
are separately perfomied, whereby, for each servtoe, 
the identification of a user, and the issuance, registra- 
tion, and management of publte key certificates are not 
required to be newly configured in the same way as in 
a conventional system, whereby a new service using a 
public key and a pubte key certificate can be started by 
using existing data to configuring only necessary part. 
[0049] In the present invention, a public-key-certifi- 
cate issuer authority executes public-key-certlficate is- 
suing processing, and a root registration authority exe- 
cutes the management of users who use publk: key cer- 
tificates issued by the public-key-certificate issuer au- 
thority. Accordingly, a public key certificate issued by the 
public-key-certificate issuer authority can be used in 
comnrK>n In various services provided by a plurality of 
servtee providers (registration authorities orservk:e pro- 
viders managed by the registration authority), whereby 
a servk^ provider that will provide a new servbe does 
not need to configure a registration authority function. 
[0050] I n addition, since a public key certificate issued 
by a public-key-certrfteate issuer authority is based on 
a standard format, it is compatible with a public key cer- 
tificate issued by an existing registration authority, 
whereby it is possible to allow an existing system and 
the system of the present invention to exist In a mixed 
fomn. 

[0051] According to the present invention, processes 
by a public-key-certificate Issuer authority, a root regis- 
tration authority, and a registration authority are sepa- 
rately perfonmed, and for each service, the identification 
of a user, and the issuance, registration, and manage- 
ment of public key certifk^ates are not required to be 
newly configured in the same way as in a conventional 
system, whereby a new servk:e using a public key and 
a publb key certifk»te can be started by using existing 
data to configuring only necessary part, whereby a load 
on the registration authority as in the conventional sys- 
tem can be reduced. 



[0052] According to the present invention, by forming 
a registration authority as a system holder that is an au- 
thority for providing or managing a contents or service 
distributing infrastructure for enabling provision of con- 
tents or services, certification and data connmunication 
using a common publte key certificate can be executed 
between different infrastructures, and In a user device, 
the use of various services provided by different provid- 
ers, or cross certification processing with another user 
devk:e can be executed using a common public key cer- 
tiftoate. 

[0053] Further objects, features, and advantages of 
the present invention will become apparent from the fol- 
lowing description of the prefen^ed embodiments with 
reference to the attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0054] 

Fig. 1 is an illustration of an example of a public key 

certificate; 

Fig. 2 is a block diagram showing an outiine of pub- 
lic-key-encryption data-communication system of 
the present invention; 

Rg. 3 is an illustration (exannple 1 ) of processes by 
a publb-key-certificate Issuer authority, a root reg- 
istration authority, and a subject to be certificated in 
a public-key-encryption data-communbation sys- 
tem of the present invention; 
Fig. 4 is an illustration (example 2) of processes by 
a public-key-certificate issuer authority, a root reg- 
istration authority, and a subject to be certificated in 
a public-key-encryption data-connmunteation sys- 
tem of the present invention; 
Fig. 5 is an illustration of the data structure of a pub- 
lic-key-certificate issuer authority In a public-key- 
encryption data-communication system of the 
present invention; 

Fig. 6 is an illustration (No. 1) of the structure of a 
public key certificate in a public-key-encryption da- 
ta-communication system of the present invention; 
Fig. 7 is an illustration (No. 2) of the structure of a 
public key certificate in a public-key-encryptton da- 
ta-communication system of the present invention; 
Fig. 8 is an illustration of a data structure in the da- 
tabase of a registration authority In a public-key-en- 
cryption data-communication system of the present 
Invention; 

Fig. 9 is an Illustration (No. 1) of the structure of a 
revocation list In a public-key-encryption data-com- 
munication system of the present invention; 
Fig. 10 is an Illustration (No. 2) of the structure of a 
revocation list in a publb-key-encryption data-com- 
munication system of the present invention; 
Fig. 11 is a flowchart illustrating sign generating 
processing applicable to a public-key-encryption 
data-communication system of the present inven- 
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tion; 

Fig. 12 is a flowchart Illustrating sign generating 
processing applicable to a publlc-key-enciyptlon 
data-communication system of the present inven- 
tion; ^ 
Fig. 13 is an illustration of cross certification 
processing applicable to a public-key/symmetric- 
key-encryption data-communication system of the 
present invention; 

Fig. 14 is an illustration of cross certification io 
processing applicable to a publk:-key-encryption 
data-communbation system of the present inven- 
tion; 

Fig. 15 is an illustration of ternis for use in a public- 
key-encryption data-communication system of the is 
present invention; 

Figs. 16A and 16B are Illustrations of pre-registra- 
tion processing between a public-key-certificate is- 
suer authority and a registration authority in a pub- 
to-key-encryption data-communk:ation system of 20 
the present Invention; 

Fig. 17 is an Illustration of pre-registration process- 
ing between a publte-key-certificate issuer authority 
and a registration authority in a public-key-encryp- 
tion data-communicatk>n system of the present in- ^ 
vention; 

Fig. 1 8 Is an illustration of offline processing among 
a public-key-certifkiate issuer authority, a registra- 
tion authority, and a user in a publte-key-encryption 
data-communteation system of the present inven- so 
tion; 

Fig. 1 9 is an iilustration of processing among a pub- 
Ite-key-certif icate Issuer authority, a root registration 
authority, a registration authority, and a user in a 
public-key-enciyption data-communication system ss 
of the present invention; 

Fig. 20 Is an illustration of key updating processing 
among a public-key-certificate issuer authority, a 
root registration auttiority, and a service provider in 
a publte-key-encryption data-communication sys- 
tern of the present invention; 
Fig. 21 is an illustration of key updating processing 
among a public-key-certificate issuer authority, a 
root registration authority, and a service provider in 
a publb-key-encryption data-communication sys- ^ 
tem of the present invention; 
Fig. 22 is an illustration of key revocation process- 
ing among a public^key-certificate issuer authority, 
a root registration authority, and a user in a public- 
key-encryption data-communication system of the so 
present invention; 

Fig. 23 is an illustration of key-revocation validating 
processing among a publk:-key-certificate issuer 
authority, a root registration authority, and a user In 
a publb-key-encryption data-communication sys- ss 
tem of the present Invention; 
Fig. 24 Is an illustration of public-key-certificate de- 
leting processing among a public-key-certifk»te is- 



suer authority, a root registration authority, and a us- 
er in a pubric-key-encryption data-communication 
system of the present invention; 
Fig. 25 is an iilustration of a system holder and otiier 
authorities in a publte-key-encryption data-commu- 
nk:ation system of the present invention; 
Fig. 26 is an illustration of specific examples of a 
system holder and other authorities in a public-key- 
encryption data-communication system of the 
present Invention; 

Rg. 27 is an illustration of an example in which a 
public key certificate is used when a system holder 
does not have a hierarchbal structure with respect 
to a root registration authority; 
Rg. 28 is an illustration of an example in which a 
public key certificate is used when a system holder 
has a hierarchical structure with resp&A to a root 
registration authority; and 
Fig. 29 is an illustration of an example in which a 
public key certificate is used among a public-key- 
certiftoate Issuer authority, a root registration au- 
thority, a registration authority, and a user in a pub- 
lic-key-encryption data-communication system of 
the present invention. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0055] Embodiments of tiie present Invention are de- 
scribed below with reference to tiie drawings. 
[0056] In Fig. 2 is shown a schematic illustration of a 
data communication system and a data communication 
method that use public-key encryption. 
[0057] In Fig. 2. a shop 206, a terminal 207, a user 
devbe 208, and a user settiement organization 209 are 
subjects to be certificated, in other words, bodies ttiat 
perfomn data transmission and reception based on pub- 
lic key encryption. Although Fig. 2 shows, as typk^al sub- 
jects to be certificated, one shop 206, one temiinai 207, 
one user device 208, and one user settiement organi- 
zation 209, In general, many types of these exist, and 
other than these, various types of subjects to be certif- 
icated can exist. 

[0058] The shop 206, the tenminal 207, the user de- 
vk:e 208, and the user settiement organization 209 as 
subjects to be certificated, which are under control of 
each registration auttiority (also Indicated by "RA" in the 
accompanying drawings), request registration authori- 
ties (service provider RAs) 203 and 204, and a registra- 
tion authority (payment RA) 205 to issue public-key cer- 
tifk^tes corresponding to public keys they use. 
[0059] The registration authorities 203, 204, and 205 
certificate subjects (entities and apparatuses partbipat- 
Ing in sen/k^es) in services, or certificate a payer for par- 
ticipators in the services (guarantee for payment). The 
registration authority 203, 204, and 205 also receive is- 
suing requests on public-key certificates corresponding 
to public keys used by the subjects (entities, apparatus- 
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es, and users participating in the services) in the serv- 
ices, and transfer them to a public-key-certificate issuer 
authority (also Indicated by an "lA" In the acconnpanymg 
drawings) 201 via a root registration authority (also in- 
dicated by a "root 1^" in the accompanying drawings) 
202. The root registration authority 202 accepts the pub- 
tic-key-certrficate issuing requests from the certifbated 
registration authorities 203, 204, and 205. In other 
words, the root registration authority 202 accepts, as the 
public-key-certificate issuing requests, only requests 
from authorities certificated by the root registration au- 
thority 202. 

[0060] In Fig. 2, the registration authorities 203 and 
204 are, for example, service providers that perform pro- 
vision of services for distributing contents such as music 
data, image data, and game programs, and the regis- 
tration authority 205 is a clearing center that perf omis 
settlement processing on users' electronic money by 
perfomning data communication with the user settle- 
ment orgcmization 209. These registration authorities 
shown In Fig. 2 are examples, and otherthan these, var- 
ious types of registration authorities that provkie various 
servk^es can exist. 

[0061] Each registration authority exists for each 
servtee (system), and the root registration authority 202 
exists as one that controls and certificates the registra- 
tion authorities. The root registration authority 202 is 
certificated by a public-key-certifk^te issuer authority 
201 , whk^h is described below. The registration author- 
ities 203, 204, and 205 are small-sized service bodies. 
When the servrce providers do not have registration au- 
thorities for them, the root registration authority 202 can 
function instead of them. 

[0062] The public-key-certificate issuer authority 201 
performs cross certifteation with the root registration au- 
thority 202 or the registration authority 203, 204 or 205, 
creates a public-key certrf bate based on a subject iden- 
tifier (ID) for identifying a subject as a public-key-certif- 
icate-issuance requesting body, a subject's public key, 
and other Infomnation to be written in the public-key cer- 
'tlficate, which are transferred from the root registration 
authority 202 or each of the registration authorities 203 
to 205, and distributes the public-key certificate to the 
Tegishgtion^uthootigs 203 to 205. 
[00^ This makes it a conditton that the root registra- 
tion authority 202 or each of the registration authorities 
203 to 205, which requests the publk:-key-certrfk:ate Is- 
suer authority 201 to issue a certificate, has been cer- 
tificated by the publk:-key-certificate issuer authority. 
[0064] Also, In response to a request from the root 
registration authority 202 or each of the registration au- 
thorities 203 to 205, the public-key-certificate issuer au- 
thority 201 performs processing for responding to the 
updating, invalidatton, and deletion of the public-key 
certifbate, or to confirmation by the subject of the valid- 
ity of the publto-key certificate. The public-key-certifi- 
cate issuer authority 201 is to be authorized by an ap- 
propriate legal organization, and is regarded as certifi- 



cated after being authorized. 

[0065] In Figs. 3 and 4 are illustrated processes in 
subjects to be certificated, such as the publb-key-cer- 
tifk:ate issuer authority 201 , the root registration author- 

5 ity 202 or the registi'ation authorities 203 to 205, the 
shop 206, the temiinal 207, the user devk:e 208, and 
tiie user settlement organization 209. 
[0066] Fig. 3 shows a case in whbh the subjects to 
be certificated, such as the shop 208, the terminal 207, 

10 the user device 208, and the user settlement organiza- 
tion 209 themselves generate publb keys and private 
keys that are applied to the public key encryption. Fig. 
4 shows a case in which tiie root registration authority 
202 or the registration authorities 203 to 205 each gen- 

f5 erate a publb key and a private key. The service provid- 
ers 304 shown In Rgs. 3 and 4 have no registration au- 
thority functions. 

[0067] Each process shown in Fig. 3 is described. The 
subject to be certif bated 303 generates a public key and 

20 a private key that are applied to the pubib key encryp- 
tion, and requests the registration autiiority 302 to issue 
a certificate corresponding to the public key. At this time, 
the subject to be certificated 303 transmits its ID and the 
public key. Its ID is, for example, a user's own identifier, 

25 a user temninal identifier, or the like. When receiving the 
infonmatlon, the registration authority 302 verifies the 
subject to be certif bated, and subsequently transfers 
the received subject ID and publb key to the public-key- 
certificate issuer autiiority 301. The publb-key-certlfl- 

30 cate Issuer authority 301 creates, based on the received 
subject ID and publb key and on other information to be 
written in the public-key certificate, the public-key cer- 
tificate, and distributes the certificate to the registration 
authority 302 via the registration authority or the root 

35 registration authority. The registration authority 302 
transfers the publb-key certificate to the subject to be 
certificated 301 . 

[0068] When executing updating processing after 
generating a new public key and a new private key, the 

40 subject to be certificated 303 transmits the newly gen- 
erated public key to the registration authority 302 with 
its ID. After verifying the subject to be certificated 303, 
the registration authority 302 transfers the received sub- 
ject ID and public key to the public-key-certif bate issuer 

45 authority 301 , the publb-key-certif icate issuer authority 
301 creates a new public-key certificate based on the 
received subject ID and public key and on other infor- 
mation to be written in the public-key certifbate, and 
transmits the certificate to the subject to be certificated 

50 via the registration authority or the root registration au- 
tiiority. 

[0069] As shown in Fig. 3, the registration authority or 
ttie root registration authority 302 performs verification 
processing on the subject to be certificated, and the 
55 holding of apparatus Infonnation and user information, 
and manages revocation of an issue by the public-key- 
certificate issuer authority 301 . 
[0070] The public-key-certificate issuer authority 301 
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performs the management of the public key on the is- 
sued public-key certificate and the ID of the subject to 
be certificated, processing for Issuing a public-key cer- 
tificate, processing for invalidating the issued public-key 
certificate, and processing for checking the validity of 
the issued public-key certificate. 
[0071 ] As for revocation proceedings, the public-key- 
certificate issuer authority 301 executes, based on a re- 
quest from the registration authority or the root registra- 
tion authority 302, processing for invalidating the issued 
public-key certificate. The registration authority or the 
root registration authority 302 notifies the subject to be 
certificated 303 and the service provider 304, which 
needs revocation notification, of the revocation. The rev- 
ocation notification can be provided as difference data 
obtained by subtracting invalidator data from the revo- 
cation data by the registration authority, whk^h manages 
the revocation list, or the registration authority 302. 
[0072] The subject to be certificated 303 can request 
the publb-key-certiflcate Issuer authority 301 to verify 
whether its public key is usable, in other words, whether 
the public-key certificate is valid. In this case, the subject 
to be certificated 303 transmits its ID and the public key 
to the public-key-certif k:ate issuer authority 301 , and va- 
lidity verification is perfomned based on public keys and 
the IDs of subjects to be certificated whk;h are managed 
by the public-key-certificate issuer authority 301 . 
[0073] Fig. 4 shows the case in which the registration 
authority or the root registration authority 302 generates 
the public key and the private key. In Fig. 4, the public 
key and the private key, generated by the registration 
authority or the root registration authority 302, are trans- 
mitted to the subject to be certif cated 303, and the sub- 
ject to be certificated 303 stores them. The subsequerit 
steps are similar to those In the processing In Fig. 3. 
[0074] Although the public-key-certificate revocation 
management in Figs. 3 and 4 is designed to be per- 
formed by the registration authority and the root regis- 
tration authority 302, the revocation management may 
be periomied by the pubtlc-key-certif k»te Issuer author- 
ity 301. 

0075] In Fig. 5 are shown main items of data man- 
aged by the public-key-certificate issuer auttiority 301 . 
"RAID" Is an identifierfor a registration authority to which 
a servk:e is provided. "ID" is an Identifierfor a subject to 
be certificated. "PUBLIC KEY" is a public key for the 
subject to be certificated, and "CERTIFICATE" is a pub- 
lic-key certificate itself. "VALIDITY FLAG" is a flag indi- 
cating whether the publk>key certificate is valid. 
[0076] In Figs. 6 and 7 Is shown a format of a public- 
key certificate. This is an example based on Publk: Key 
Certificate Fomnat X.509 Version 3, 
[0077] "version" indicates the version of a certiftoate 
format. 

[0078] "Serial Number" indicates the serial number of 
the public-key certificate which is set by the publk:-key- 
certif icate issuer authority. 

[0079] "Signature algorithm Identifier algorithm pa- 



rameter" is a field in which a signature algorithm of the 
pubiic-key certifk^ate and its parameters are recorded. 
The signature algorithm includes elliptic curve encryp- 
tion and RSA. When elliptic curve encryption is applied, 

5 parameters and a key length are recorded, and when 
RSA is applied, a key length is recorded. 
[0080] "issuer" is a field in which an issuer of the pub- 
lic-key certificate, namely, the name of the public-key- 
certificate issuer authority is recorded in a recognizable 

10 form (Distinguished Name). 

[0081] In "validity", a start date and time, and an end 
date and time are recorded which constitute a certificate 
validity period. 

[0082] In "subject", the name of a subject to be certif- 
is teated, as a user, is recorded. Specifically, it is, for ex- 
ample, the ID of a user apparatus, the ID of a servtee 
providing body, or the like. 

[0083] "subject Public Key Info algorithm subject Pub- 
lic key" is a field for storing a key algorithm and key in- 

20 fonmation as user's public key Infonnation. 

[0084] These fields are included in publk:-key-certifi- 
cate format X.509 Version 1 . The following are fields 
added in public-key-certificate format X.509 Version 3. 
[0085] "authority Key Identifier-key Identifier, authori- 

25 ty Cert Issuer, authority Cert Serial Number" is informa- 
tion for identifying a key to the public-key-certificate is- 
suer authority, and stores a key identifbation number 
(octal number), the name of the publb-key-certiticate is- 
suer authority, and an identification number. 

30 [0086] "subject key Identifier" stores an identifier for 
identifying each key when a plurality of keys are certifi- 
cated in the public-key certificate. 
[0087] "key usage" is a field which designates a use 
of a key, and in whteh one of uses: (0) digital signature, 

3S (2) key enciphemient, (1) non-repudiation, (3) data 
(message) encryption, (4) symmetric key transfer, (5) 
verification of a signature for certification, or (6) verifica- 
tion of signatures on the revocation list. 
[0088] In "private Key Usage Period", the effective 

40 date of a private key retained by the user is recorded. 
[0089] In "certiftoate Polk:ies", certificate issuance 
policies of the certificate authority, or the public-key cer- 
tif icate issuer authority and the registration authority are 
recorded. They mean, for example, a policy ID in ao- 

^ cordance with ISO/IEC 9384-1 , or a certificate standard. 
[0090] "polby Mapping" is a field used only when the 
CA (public-key-certificate issuer authority) is certificat- 
ed, and defines the policies of the public-key certificate 
issuer authority and the mapping of the policies to be 

50 certificated. 

[0091 ] "supported algorithms" defines the attribute of 
a directory (X.500). This is used such that, when another 
system with which communk^ation is established uses 
directory information, its attribute is posted beforehand. 

55 [0092] "subject Alt Name" is a field in whk:h another 
name of the user is recorded. 
[0093] "issuer Alt Name" is a field in which another 
name of the certificate issuer is recorded. 
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[00941 "subject Directory Attribute" is a field in which 
user's arbitrary attributes are recorded. 
[0095] "basic Constraint" is a field for determining 
whether the public key to be certificated is for signing by 
the certificate authority (public-key-certificate issuer au- s 
thority) or is of the user. 

[0096] "name Constraints permitted Subtrees" is a 
field indk»ting the effective range of a certificate used 
only when a subject to be certificated is the certlfk^ate 
authority (public-key-certificate Issuer authority). io 
[0097] "policy Constraints" describes a specif to certif- 
icate policy ID con^ponding to the remainder of certif- 
icate paths, and a prohibition policy map. 
[0098] "Certificate Revocation List Distribution 
Points" is a field to describe reference points of the rev- is 
ocatlon list (see Fig. 9) that is used to conflnm whether 
the certificate has been revoked when the user uses the 
certifk:ate. 

[0099] "signature" is a field for a signature of a public- 
key-cerdficate issuer (public-key-oertificate issuer au- 20 
thority). 

[0100] In Fig. 8, the data structure of an entity data- 
base in the registration authorities in Figs. 3 and 4 is 
shown. The entity database is designed to manage sub- 
jects to be certlfteated. 25 
[01 01] -ID" Is a fiekl storing the Identifiers of the sub- 
jects to be certif bated. 

[0102] In "certificate data", information required for 
certificating the subjects to be certificated, for example, 
user terminal IDs when user terminals are to be certif i- so 
cated, etc., are recorded. 

[0103] In "certification results", last certification re- 
sults are recorded. 

[01 04] I n "revocation Inf onnation", pointer information 

to the revocation list are recorded. 35 

[0105] In Figs. 9 and 10 are shown fomnat examples 

(based on X.509 V2) of the revocation lists. Fig. 9 shows 

common items, and Fig. 10 shows Inf onnation managed 

by each certificate. Each Item Is described. 

[0106] "signature Algorithm Identifier" describes a 40 

signature algorithm about a signature to be applied. For 

example, it is elliptic curve encryption or RSA. 

[0107] In "Issuer", the issuer of the revocation list is 

recorded. In the examples In Figs. 3 and 4, the name of 

the registration authority Is recorded. ^ 

[0108] In This Update", the issuance date and time 

of the revocation list is recorded. 

[0109] In "Next Update", the next date and time of the 

updating of the revocation list Is recorded. 

[0110] In "Version", the version of the revocation list so 

Is recorded. 

[Oil 1 ] "authority Key Identifier-key Identifier, authori- 
ty Cert Issuer, authority Cert Serial Number' is informa- 
tion for identifying a key to the publk^key-certificate is- 
suer authority, and stores a key Identification number ss 
(octal number), the name of the public-key-certlflcate is- 
suer authority, and a certifbate number. 
[01 12] In "CRL Number", the issuance serial number 
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of the revocation list Is recorded. 
[Ql 13] In revocation list information ("Issuing distribu- 
tion pointy, various types of inf onnation on the revoca- 
tion list are recorded: a distributor name ("Distribution 
point"), infonnation ("only contains user certs") on 
whether the revocation list Is used dedk»tedly for sub- 
scriber revocation, infonnation on whether the revoca- 
tion list is used dedicatedly for revocation of the ceriifi- 
cate by the certrf toate authority (in this enr)bodiment, the 
public-key-certlfk^te issuer authority), and Infonnation 
("only some reasons") on whether there are other revo- 
cation reasons, and whether the revocation list is an In- 
direct revocation list ("indirect CRL"). The Indirect revo- 
cation list ("indirect CRL") is a fonn in which the nr^n- 
agement of Information on revocation reasons and the 
management of the revocation list are perfonned by 
separate organizations. For example, in a case in which 
the root registration authority issues the revocation list, 
and the publk:-key-certif icate Issuer authority manages 
the public-key-ceriifk»te Issuer authority, the form is de- 
fined as the Indirect revocation list (Indirect CRL). In this 
case, revocation information storing points, for example, 
data that represent I A identifiers are stored. According 
to the construction of the present invention, the revoca- 
tion list Is generated as the Indirect revocatton list (Indi- 
rect CRL), and the Information on revocatton reasons is 
managed not by a revocation list issuer but by the publlc- 
key-certifk^ate issuer authority. 
[01 14] In a CRL identifier difference ("Delta CRL Indi- 
cator"), data on whether the revocation list is distributed 
as a difference list are recorded. The difference list is a 
list stmcture in whfch public-key information on deter- 
mined revocation, extracted from public-key infonnation 
on revocation options, is designed to be providable to a 
related provider. 

[0115] Fig. 10 is an Illustration of Infonnation man- 
aged by each certif cate. 

[0116] In "certif k:ate Serial Number", a certificate 
number Is recorded. 

[Ql 17] In "Revocation Date", the date and time of ac- 
ceptance of an application for revocation is recorded. 
[01 18] The fields in so far are fields defined in version 
1 , and the following ones are fields defined in Version 2. 
[01 19] "Reason code" Is a fieM to describe revocation 
reasons. Revocation reasons are as follows: 0: reason 
unknown; 1: subscriber compromised; 2: CA (public- 
key-certifbate issuer authority) key compromised; 3: 
certificate information has changed; 4: the certificate 
has got replaced; 5: suspension of use; 6: temporary 
suspenston of use; and 7: release of temporary suspen- 
sion state. 

[0120] "Hold instruction code" describes a method of 
coping with the temporary suspension of use. 
[0121] "Invalidity date" describes a date and time at 
which the private key may have been damaged. 
[0122] "certif k:ate issuer" describes the name of the 
certificate authority. IHowever, in the case of the Indirect 
revocation list, revocation Information is not managed 
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by the revocation list Issuer authority. Accordingly, a 
designated revocation information management CA (e. 
g., the public-key-certificate Issuer authority) is used to 
make a detour, in other words, a pointer to the I A is set. 
[01 23] "signature" is a signature of the revocation list 5 
issuer. 

[0124] An electronic signature and cross certification 
processing, used in the pubiic-key-certrfbate issuing 
system and data communrcation method of the present 
invention, are described. After describing the electronic io 
signature and cross certification processing, details of 
specific processing in the public-key-certifk»te issuing 
system of the present invention are described below 
with reference to the drawings. 

15 

Electron k; Signature 

[01 25] A method of generating an electronk: signature 
by using the publb key encryption is described below 
with reference to Fig. 11 . The process shown in Rg. 11 20 
is a process flow of generating elec^ronk: signature data 
using EC-DSA ((Elliptic Curve Digital Signature Algo- 
tlthm), IEEE P1363/D3). Here, an example that uses the 
Elliptb Cun^e Cryptography (hereinafter referred to as 
the ECC) as the publk: key encryption is described. In 25 
the data processing according to the present invention, 
in addition to the elliptic curve cryptography, for exam- 
ple, the RSA encryption ((Rivest, Shamir, Adteman), 
etc., (ANSI X9.31)) in a similar public key encryption 
may be used. so 
[0126] The steps in Fig. 11 are described. In step 81 , 
a characteristk; is represented by p, coeffteients of an 
elliptte curve (elliptic curve: y^ = x^ -f ax + b) are repre- 
sented by a and b, a base point on the elliptk: curve is 
represented by Q, an order of G is represented by r, and 3S 
a private key is represented by Ks (0 < Ks < r). In step 
S2, a hash value of message M is calculated, and it is 
assumed that f Hash(M}. 

.01 27] Here, a method of finding a hash value by us- 
ing the hash function is described. The hash function is 40 
a function in which an input message is compressed into 
data having a predetemiined bit length and the data is 
output as a hash value. The hash function has features 
iri^at it is difficult to predk:t an input from a hash value 
output), in that many bits of the hash value are changed 45 
hen one bit of data input to the hash function, and in 
that It is diffteult to find out different input data having the 
same hash value. As the hash function, MD4, MD5, 
SHA-1 , or the like, may be used, or DES-CBC may be 
used. In this case, MAC (check value: corresponding to so 
\CV) that is used as a final output value becomes a hash 
aiue. 

[0128] Subsequently, in step S3, a random number u 
(0 < u < r) is generated, and in step S4, coordinates V 
(Xv, YV) that is obtained by mu Itiplying the base point by ss 
u times is cateulated. Addition and doubling on the elllp- 
tk: curve are defined as follows: 



If P = (Xa, Ya), Q = (Xb, Yb), and R = (Xc. Yc) = P 
Q, when P ^ Q (addition). 

Xc = X2 - Xa - Xb 

Yc = Xx (Xa-Xc)-Ya 

X=(Yb-Ya)/(Xb-Xa) 

when P = Q (doubling), 

Xc = X2-2Xa 

Yc = Xx (Xa-Xc)-Ya 

X=(3(Xa)2 + a)/(2Ya) 

[0129] Using these, a value that is u times the point 
G is calculated (although the speed is slow, the following 
is used as the most understandable operation method: 
G, 2 X G, and 4 x G are calculated, u is expanded in 
binary number, and corresponding 2* x G (a value ob- 
tained by doubling G i times (i is a bit position counted 
from the LSB of u)) is added to a position having 1 . 
[0130] In step S5, c = Xvmod r is calculated, and irP" 
step S6, it is determined whether this value is zero. If y 
this value is not zero, d = [(f + cKs)/u] mod r is calculated / 
in step S7, and it is determined in step S8 whether d is( 
zero. If d is not zero, In step S9, c and d are output as 7 
electronk: signature data. If it is assumed that r has a bit I 
length of 1 60 bits, the electrons signature data has a bit j 
length of 320 bits. n — — ^ 
[0131] If c is zero in step S6, the process proceeds 
back to step S3, and generates a new random number 
again. SImilariy, If d Is zero in step 88, the process pro- 
ceeds back to step S3, and generates a random number 
again. 

[0132] Next, a method of verifying the electronic sig- 
nature by using the public key encryption Is descrit)ed 
below with reference to Fig. 1 2. In step S11 , a message 
is represented by M, a characteristb is represented by 
p, coeffk:ients of an eiliptk^ curve (elliptic curve: y^ = x^ 
+ ax -h b) are represented by a and b, a base point on 
the elliptic curve Is represented by G, an order of G is 
represented by r, and G and Ks x G are used as a publte 
key (0 < Ks < r). In step S12, it is determined whether 
electronic signature data c and d satisfy 0 < c < r and 0 
< d < r. If these conditions are satisfied, in step SI 3, a 
hash value of the massage M is calculated, and it is as- 
sumed that f = Hash(M). Next, in step S14, h = 1/d mod 
r is calculated, and in step S15, hi = fh mod r and h2 = 
ch mod r are calculated. 

[0133] In step SI 6, using the already cateulated h1 
and h2, point P = (Xp, Y|3) = hi x G -i- h2 K8 x G is cal- 
culated. Since an electrons signature verifier knows 
public keys G and Ks x G, the verifier can perform cal- 
culation of multiplying a point on the elliptic curve by a 
scalar times, similariy to step S4 in Fig. 11 . In step SI 7, 
it is determined whether the point P is a point at infinity. 
If the point P is not a point at infinity, the process pro- 
ceeds to step S18 (actually, detennlnation on the point 
at infinity can be performed In step SI 6. In other words. 
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addition for P = (X, Y) and Q = (X, -Y) makes it impos- 
sible to calculate X, and it is found that P + Q is a point 
at infinity). In step SI 8, Xp mod r is calculated, and Is 
compared with electronic signature data c. When these 
values are finally Identical, the process proceeds to step j 
SI 9, and detemiines that the electronic signature is cory 
rect. / 
[0134] If the process has detemfiined that the elecl- 
tronic signature is correct, the data is not manipulated, 
and it is found that a person who retains a private kej 
corresponding to the public key has generated the elec-\ 
tronic signature. 

[0135] If the electronic signature data cord does not / 
satisfy 0<c<rorO<d<r, the process proceeds to 
step S20. Also if the process has determined in step SI 7 
that the point P is a point at infinity, it proceeds to step ' 
S20. Also if the value of Xp mod r Is not coincident with 
the electronic signature data c, the process proceeds to 
step S20. 

[01 36] If the process has detenmi ned in step S20 that 
the electronic signature is not con-ect, it is f ou nd that the 
data is manipulated and it is found that a person who 
retains a private key con'esponding to the publte key has 
not generated the electronic signature. . 

Cross Certiftoation 

[0137] Between two means executing data transmis- 
sion and reception, after both verifies each other as a 
correct data communicator, both transfer necessary da- 
ta to each other. Verification processing on whether both 
means are correct data communicators is cross certifi- 
cation processing. It is one pretended data transfer meth- 
od that, after the generation of a session key is per- 
fomned in the cross certification processing, data trans- 
mission is perfomried executing encryption processing 
with the generated session key as a public key. 
[01 38] Cross certification using the public key encryp- 
tion is described below with reference to Rg. 13. In Fig. 
1 3, DES is used as the publk; key encryption, but a sim- 
ilar type of public key encryption may be used. 
[01 39] At first, "B" generates a 64-bit random number 
Rb. and transmits Rb and ID(b) that is an ID of itself to 
A. When receiving theses, "A" generates another 64-bit 
random number Ra, and uses key Kab in the CBC mode 
of DES to encrypt the data in the order of Ra, Rb, and 
lD(b), and sends the encrypted data back to B. 
[01 40] When receiving the encrypted data, B uses the 
key Kab to decrypt the received data. In a method of 
encrypting the received data, first, by using the key Kab 
to decrypt a ciphertext E1 , the random number Ra is 
obtained. Second, by using the key Kab to decrypt a ci- 
phertext E2, and perfonning exclusive logical addition 
of the decrypted result and El , Rb is obtained. Finally, 
by using the key Kab to decrypt a ciphertext E3. and 
performing exclusive logical addition of the decrypted 
result and E2, iD(b) is obtained. Among Ra, Rb, and ID 
(b) obtained as described above, B verifies whether Rb 



and ID(b) are identical to those transmitted by B. If the 
^ verification is affirmative, B certificates that A is correct. 

[0141] Next, B generates a Session Key (hereinafter 

referred to as a Kses) that is used after the certif k^ation 
5 (the generating method uses a random number). B uses 

the key Kab in the CBC mode of DES to encrypt Rb, Ra. 

and Kses in the order given, and sends the encrypted 

data back to A. 

[0142] When receiving these, A uses the key Kab to 
10 decrypt the received data. Since a method of decrypting 
the received data is similar to that perfomned by B, Its 
details are omitted. Among Rb, Ra, and Kses obtained 
as described above, A verifies whether Rb and Ra are 
identical to those transmitted by A. If the verification is 
15 afflmiative, A certifies that B is correct. After both certif- 
k:ate each other, the session key Kses is used as a sym- 
metric key for secret communteation after the certifica- 
tion is perfomned. 

[0143] If incorrectness and inconsistency are found 
fo when verifying the received data, the cross certification 
\ is regarded as failing, and processing is discontinued. 
I [0144] Next, a cross certification method using a 
} 1 60-brt elliptb curve encryption as a pubKic-key encryp- 
tion method is described with reference to Fig. 14. In 
25 Fig. 1 4, ECC Is used as a public-key encryption method, 
but a similar public-key encryption method may be used 
as described above. Also the key size may not be 160 
bits. In Fig. 14, first, B generates and transmits 64-bit 
random number Rb to A. When receiving it, A newly gen- 
30 erates 64-blt random number Rb and random number \ 
Ak smaller than characteristic p. A finds point Av = Ak x 1 
G, which is Ak times the base point G, and generates 
and sends electronic signature A.Sig con'esponding to 
Ra, Rb, and Av (X coordinate and Y coordinate) back to 
35 B, with a pubib key certificate of A. Here, Ra and Rb 
each have 64 bits, and the X coordinate and Y coordi- 
nate of Av each have 160 bits. Thus, an electronic sig- 
nature corresponding to a total of 448 bits is generated. 
Since the electronic signature generating method has 
40 been described with reference to Fig. 11 , its details are 
omitted. 

[0145] When using a public key certificate, the user 
uses a public key of the public-key-certif icate issuer au- 
thority 410, whtoh is retained by the user, to verify an 

45 electronic signature of the public key certificate. After 
succeeding in the verif k^ation of the electronic signature, 
the user extracts the public key from the publk; key cer- 
tificate, and uses the obtained public key. Accordingly, 
all users who use the public key certificate must retain 

50 public keys of a common pubiic-key-certificate issuer 
authority. Since the electronic signature verifying meth- 
od has been described with reference to Fig. 12, its de- 
tails are omitted. 

10146] Refening backto Rg. 2, the description is con- 
55 tinued. When receiving the publk: key certificate of A, 
Ra, Rb, Av, and the electronic signature A.Sig, B verifies 
whether Rb transmitted from A is Identical to that sent 
by A. As a result, if the verif k:atlon is affirmative, B uses 



12 



23 



EP1 130 844 A2 



24 



a public key of the certificate authority to verify the elec- 
tronic signature in the public key certificate of A, and 
extracts the A's public Icey. B uses the extracted public 
key of A to verify the electronic signature A.Sig. Since 
the electronic signature verifying method has been de- 
scribed with reference to Fig. 12. its details are omitted. 
After succeeding in the verification of the electronic sig* 
nature, B certifies that A is connect. 
[01 47] Nest, B generates random number Bk smaller 
than characteristic P. B finds point Bv = Bk X G, which 
Is a value obtained by multiplying base point G by Bk 
times, and generates and sends electronic signature B. 
Sig that corresponds to Rb, Ra, and Bv {X coordinate 
and Y coordinate) back to A, with a public key certificate 
of B. 

[01 48] When receiving the public key certifbate of B. 
Rb, Ra, Av, and the electronfc signature B.Sig, A verifies 
whether Ra transmitted by B is identical to that gener- 
ated by A. As a result, if both are identical, A uses the 
public key of the certificate authority to verify the elec- 
trons signature in the public key certificate of B, and 
extracts the pubib key of B. A uses the extracted public 
key of B to verity the electronic signature B.Sig. After 
succeeding in the verification of the electronic signature, 
A verifies that B is correct. 

[0149] When both succeed in certifbation, B cabu- 
lates Bk x Av (although Bk is a random number, it is 
required to perfonr^ multiplication by a scalar times since 
Av is a point on the elliptic curve), A cabulates Ak x Bv, 
and the lower 64 bits of the X coordinates of these points 
are used as a session key for subsequent communk^a- 
tion (in a case in which the symmetric encryption is de- 
signed to symmetric encryption using a 64-bit key 
length). Definitely, the session key may be generated 
from the Y coordinates, and the lower 64 bits may not 
be used. In secret communteation after the cross certi- 
fication, in addition to session-key encryption, an elec- 
tronic signature may be put on transmission data. 
[0150] When Incorrectness and Inconsistency are 
found In the verification of the electron^ signature and 
the verifteation of the received data, the cross certifica- 
tion is regarded as failing, and the processing is discon- 
tinued. 

[0151] In the above-described cross certifbation 
processing, the generated session key Is used to en- 
crypt transmission data, and mutual data communba- 
tion is executed. 

[0152] In Fig. 15 is shown descriptions of terms that 
are used in the following description and that are related 
to the publte-key-certif icate issuing system and the data 
communication method of the present invention. These 
are briefly described. A key is represented by K, P is 
added as a suffix to mean a public key, S Is added as a 
suffix to mean a private key, and an owner Identifier (e. 
g., a) Is added. A session key that is generated in cross 
certification for use in encryption and decryption 
processing is represented by Ks. A public key certif bate 
of B, issued by A, is represented by A«B». Concerning 



the encryption of data, for example, data encrypted us- 
ing the session key Ks is represented by EKs(data). Sim- 
ilarly, decrypted data is represented by DKs(data). Con- 
cerning signature processing, for example, data signed 

5 using the private key Ksa of A Is represented by {data) 
Sig-Ksa. Conceming encrypted signed data, what Is ob- 
tained by using the session key Ks to encrypt "datattsig- 
nature" that is generated by signing data using the pri- 
vate key Ksa of A is represented by EKs({data)Sig Ksa). 

10 [01 53] Figs. 1 6A and 1 6B show processes executed 
in the process of registering the root registration author- 
ity. Fig. 16A shows an online case, and Fig. 16B shows 
an offline case. Processing order is indbated by num- 
bers. Tlie online case in Fig. 16A is described. In the 

15 online case, between the root registration authority 1 601 
and the publio-key-certificate issuer authority 1602, the 
cross certification described with reference to Figs, 13 
and 1 4 is executed using a pair of public keys of the root 
registration authority which are transfenred to the root 

20 registration authority beforehand via another route 
which Is not shown, whereby both recognizes each oth- 
er for communication, and the sessbn key Ks is gener- 
ated. 

[0154] Afterthecrossceitificatlon processing ends, the 

25 root registration authority 1601 generates Its pubib key 
and private key, and requests the publb-key-certifbate 
issuer authority 1 602 to issue a publb key certifbate cor- 
responding to the generated publb key. The request for 
issuing the certificate Is performed such that the root reg- 

30 Istration authority 1 601 transfers, to the publb-key-certif- 
icate issuer auttiority 1602, EKs({RootRAlD. Kp- 
RootRA'}sig.KsRootRA) ^^t is data encrypted using the 
session key Ks fertile identifier RootRAlD of tiie root reg- 
istration authority 1601 and the pubib key KpRootRA' of 

35 the root registration authority 1 601 . 

[0155] After decrypting the received encrypted data 
EKs({RootRAID, KpRootRA'}sjg,KsRootRA). and verifying 
the signature, the publb-key-certif Icate issuer authority 
1 602 stores the public key KpRootRA' of the root regls- 

40 tration authority 1 601 as data to be managed in a data- 
base. In other words, the public-key-certificate issuer 
authority 1602 stores it as data in the database previ- 
ously described with reference to Fig. 5. 
[0156] In response to the certifbate issuing request 

45 from the root registration authority 1 601 , the publb-key- 
certiticate issuer authority 1 602 generates the publb key 
certifbate. This is a public key certificate in accordance 
with the formats in Rgs. 6 and 7. The publb-keycertifl- 
cate issuer authority 1602 stores the generated publb 

so key certificate In the database for management (see Fig. 
5). Also, by signing tiie publb key certificate of the root 
registration authority 1601 whbh is issued by the publb- 
key-certifbate issuer auttiority 1602, namely, 
IA«RootRA» by using the private key KsIA of tiie publb- 

55 key-certificate issuer authority 1 602, and encrypting it us- 
ing the session key Ks generated in the previous cross 
certification, the publb-key-certificate issuer authority 
1 602 generates ttie data Eks({IA« RootRA»}sig.KsiA). 
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transmits the generated data to the root registration au- 
thority 1601 . The root registration authority 1601 stores 
the transmitted data. Secret information both have in 
c(^mon b^orehand may be a symmetric Icey. In this 
case, SigKsRootRA is an MAC value with the symmetric 
key used. 

[0157] When the public-lcey-certificate issuer author- 
ity 1602 uses the registration authority to directly issue 
the public key certificate without using the root registra- 
tion authority, the processing is such that the root reg- 
istration authority 1601 in Fig. 16 is replaced by the reg- 
istration authority. 

[0158] Fig. 16B shows an offline case in which the 
registering process is executed via a storage medium, 
for example, a DVD, a CD, a memory card, etc. In the 
offline process case, the processing is executed by stor- 
ing, in a storage medium, the information described 
about the offline process. 

[01 59] Fig. 1 7 shows an example of a procedure per- 
formed when a registration authority 1701 performs the 
Issuance of a publk: key certifk:ate in a case in which, 
under management by the root registration authority 
1 601 , there is the registration authority 1 701 , which op- 
erates as, for example, a servk:e provider providing a 
service of distributing contents such as music data and 
image data, or as a servtee provider performing 
processing for electron te money settlement. The exam- 
ple is described in the order of the procedure. 
[01 60] First, cross certification processing is executed 
between the registration authority 1 701 and the root reg- 
istration authority 1601. This is executed using, for ex- 
ample, cross certification keys (corresponding to the key 
Kab described with reference to Fig. 13) that are stored 
beforehand the memories of the registration authority 
1701 and the root registration authority 1601. 
[01 61 ] Second, the registration authority 1 701 signs the 
identifier SPID of the registration authority 1701 using its 
private key KgSp, generates the data EKs({SPID}sig.KsSP) 
by performing encryption using the session key Ks gener- 
ated in the cross certification, and transmits the generated 
data to the root registration authority 1601 . After using the 
session key Ks to decrypt the received data and verifying 
the signature, the root registration authority 1601 recog- 
nizes the signature and executes the signing of the recog- 
nition result, and performs encryption using the session 
key and executes recognitk)n responding to the registra- 
tion authority 1701. 

[01 62] When receiving the recognition response from 
the root registration authority 1601 , the registration au- 
thority 1701 generates its publb key and private key, 
signs the public key KpSP' using its private key, and en- 
crypts the signed public key using the session key to 
generate the data EK3({KpSp'}3|g.Kssp). The registration 
authority transmits the generated data to the root regis- 
tration authority 1601 . When receiving the data, the root 
registration authority 1601 executes the requesting of 
the pubtic-key-certifbate issuer authority 1602 to issue 
a publk; key certif k:ate of the registration authority 1 701 . 



Cross certification processing is performed between the 
root registration authority 1601 and the publk:-key-cer- 
tifbate issuer authority 1602. 

[0163] When certification is established in the cross 
5 certification processing, the root registration authority 

1 601 executes the signing of the identifier SPID of the 
registration authority 1 701 and the public key KpSp of 
the registration authority 1 701 by using the private key 
of the root registration authority 1 601 , generates E^s 
({SPID, KpSP'ls^KsRootsp) by performing encryption 
using the session key generated in the cross certiftea- 
tion, and transmits the generated data to the public- 
key-certificate issuer authority 1602. 
[0164] The publc-key-certificate issuer authority 

1602 decrypts the received data Eks((SP1D, Kp- 
^^'Isig KsRoatsp)* stores the public key KpSP of the 
registration authority 1 701 as management data in a da- 
tabase. In other words, it is stored as data in the data- 
base described with reference to Fig. 5. 
[01 65] The pubte-key-certrficate issuer authority 1 602 
further generates a publte key certifk^ate of the registra- 
tion authority 1701 . This is a publte key certificate in ac- 
cordance with the formats in Figs. 6 and 7. The publ'c- 
key-certificate issuer authority 1 602 stores the generated 
public key certificate in the database for management 
(see Fig. 5). The publk:-key-cerfificate issuer authority 
1602 also uses the private key KsiA of the publb-key- 
certfficate issuer authority 1 602 to sign the publk: key cer- 
tificate of the registration authority 1 701 , namely, IA«SP>» , 
which is issued by the publte-key-certifkkite issuer au- 
thority 1 602, generates the data FKs({IA«SP>»}s{g.K8iA) 
perfomning encryption using the session key gener- 
ated in the cross certification processing, and transmits 
the generated data to the root registration authority 1 601 . 
The root registration authority 1 601 verifies the signature, 
uses its private key to perform sign the received data, and 
encrypts the signed data using a session key (the session 
key generated in the cross certifk»tion processing exe- 
cuted between the registration authority 1701 and the 
root registration authority 1 601). The root regi^ration au- 
thority 1 601 transmits the encrypted data to the registra- 
tion authority 1 701 . After using the session key to decrypt 
the received data, and verifying the signature, the regis- 
tration authority 1701 stores the certificate. 
[01 66] In the above-descn'bed procedure, by omitting 
(5) the key generating process, the key that is embed- 
ded in a device of the registration authority 1701 may 
be used as a pubib key. In addition, by performing cross 
certification in which an initially embedded key is used 
as a symmetric key. a signature on (2) the data may be 
an MAC generated using the symmetric key 
[0167] Fig. 18 illustrates a construction in whbh the 
process, whk^h is described with reference to Fig. 1 7, of 
issuing the public key certiftoate of the registration au- 
thority 1 701 is executed in offline. The data transmitted 
between the authorities are processed such that they 
are exchanged using various storage media, for exam- 
ple, a DVD, a CD, a memory card, etc. In the offline prec- 
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ess case, the information that is described about the of- 
fline process is stored in a storage nnedium for process- 
ing. 

[01 68] Fig. 1 9 shows an example of a procedure per- 
fonned when a user 2001 (Including a shop or the like) 
perfonns the issuance of a public key certifcate in a 
case in which, under management by the registration 
authority 1701, there is a user who uses contents, a 
shop that sells contents, or the like. The example is de- 
scribed in the order of the procedure. 
[0169] In a devtee of the user 2001. the public key 
KpUD and private key KsU D of the user device, the pub- 
Ite key KpRA of the registration authority 1 701 , and the 
public key KplA of the public-key-certificate issuer au- 
thority 1602 are embedded as initial embedded keys, 
for example, in a memory in an SAM (secure Applbation 
module). 

[0170] First, the user 2001 and the registration author- 
ity 1701 execute cross certification processing, and a 
session key is generated In the cross certifk:ation 
processing. This Is performed using KpUD stored be- 
forehand in the user 2001 . 
[0171] Next, the user 2001 uses its private key 
to sign the identifier SAMID of the user 2001 , generates 
the data EKs({SPID)sig.KsiA) by perfomning encryption 
using the session key Ks generated in the cross certifi- 
cation, and transmits the generated data to the root reg- 
istration authority 1 701 . The registration authority 1701 
uses the session key Ks to decrypt the received data, 
recognizes the identifier SAMID, and executes signing 
processing on the recognition result. The registration 
authority 1 701 also uses the session key to perform en- 
cryption, and executes recognition responding to the us- 
er 2001. 

[0172] When receiving the recognition response from 
the registration authority 1 701 , the user 2001 generates 
its public key and private key, uses its private key KsUD 
to sign the public key KpUD', and generates the data 
^KsK^^UDlsin KsiA) ^y porffomning encryption using the 
session key. The user 2001 transmits the generated da- 
ta to the registration authority 1701 . 

^ [0173] When receiving the data, the registration au- 
thority 1701 executes cross certification with the root 
registration autRoril^l'BOl , and gen erates a sessio n 
key. Next, the registration authority 1 701 uses Its private 

/ Ice^KsRA to s ign the identj fier SAMID and public key 
KpUD of the user 2001 , uses the sessiori key Ks2 to 
encrypt the si gned key s, and transmits the encrypted 

I keys to the root registration authofifyTeoi. 

I [0174] The root registration authority 1601 performs 
decryption and verification processes by using the data- 
related session key transmitted from the registration au-. 
thority 1 701 , and*executes t he requesti ng of the pubtic- 
key-certificate issuer authority 1 602 to issue a certif k:ate 
of the user 200irrn addition, the root registration^ au- 
thority 1 601 and the publlc-keyK»rtificate issuer author- 

^ ity 1602 execute cross certification processing. 

[0175] When certification is established in the cross 



certification processing, the root registration authority 

1 601 uses the private key of the root registration author- 
ity 1601 to execute the signing of the identifier SAMID 
and public key KpUD of the user 2001 . and generates 

5 Eks({SAMID, KpUD}sig.KsRooiSp) by performing encryp- 
tion of the keys using the session key generated in the 
cross certification. The root registration authority 1601 
transmits the generated data to the public-key-certifi- 
cate issuer authority 1 602. 

10 [0176] After decrypting the received data E|^({SA- 
MID. KpUD}sig.KsRooisp)* verifying the signature, 
the public-key-certificate issuer authority 1602 stores 
the public key KpUD of the user 2001 as management 
data in the database. In other words, the publb-key-cer- 

is tif teate Issuer authority 1 602 stores It as data In the da- 
tabase described with reference to Rg. 5. 
[0177] The publfc-key-certificate issuer authority 

1 602 further generates a public key certificate of the us- 
er 2001 . This is a public key certificate in accordance 

20 with the fomnats in Figs. 6 and 7. The publk^-key-certif- 
icate issuer authority 1602 stores the generated public 
key certificate In the database for management (see Fig. 
5). The public-key-certrficate issuer authority 1602 also 
uses the private key KsIA of the pubtic-key-certifteate 

25 issuer authority 1602 to sign the public key certifrcate, 
namely, IA«UD» of the user 2001, whbh is issued by 
the public-key-certificate issuer authority 1602. and 
generates the data E|^({IA«UD»}sig.KsiA) by perfomri- 
Ing encryption using the session key Ks3 generated in 

30 the cross certification processing. The public-key-certif- 
icate issuer authority 1 602 transmits the generated data 
to the root registration authority 1 601 . The root registra- 
tion authority 1601 verifies the signature, and uses its 
private key to sign the received data. The root registra- 

35 tion authority 1601 encrypts the signed data by using 
the session key (the session key generated in the cross 
certification processing executed between the registra- 
tion authority 1701 and the root registration authority 
1 601 ), and transmits the encrypted data to the registra- 

40 tion authority 1 701 . The registration authority 1 701 fur- 
ther uses its private key to sign the received data, en- 
crypts the signed data by using the session key (the ses- 
sion key generated in the cross certification processing 
executed between the user 2001 and the registratk>n 

45 authority 1 701 ), and transmits the encrypted data to the 
user 2001 . After decrypting the received data using the 
session key, and verifying the signature, the user 2001 
stores the certif k:ate. 

[0178] In the above-described procedure, by omitting 
so (5) the key generating process, the key embedded in 
the device of the user 2001 may be directly used as a 
public key. in addition, by perionning cross certification 
in whfeh an initially embedded key is used as a symmet- 
ric key, a signature on (2) the data may be an MAC gen- 
55 erated using the symmetric key. 

[0179] Fig. 20 is an illustration of a procedure or up- 
dating processing in which a service provider as the reg- 
istration authority 1701 under management by the root 
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registration authority 1601 generates a new public key 
and private key and perfonns issuance of a certificate 
of the newty generated public key. 
[0180] The registration authority 1701 generates a 
new public key and private key. Next, the registration 
authority 1701 and the root registration authority 1601 
execute cross certlfk^ation processing. This can be ex- 
ecuted as cross certification processing using the 
present keys (the public key and the private key at the 
present time (before updating)), i.e., processing using 
asymmetric key encryption described with reference to 
Fig. 14. 

[0181] Next, the registration authority 1701 uses its 
private key to sign the public key KpSP' that is newly 
generated by the registration authority 1 701 , generates 
the data EKs({KpSPls,g.Kssp) by performing encryption 
using the session key generated in the cross certifica- 
tion processing, and transmits the generated data to the 
root registration authority 1 601 . When receiving the da- 
ta, the root registration authority 1 601 executes revoca- 
tion checking. The revocation checking is executed as 
the writing of public key data to be revoked in the revo- 
cation list described with reference to Figs. 9 and 10. 
[01 82] The root registration authority 1 601 further ex- 
ecutes the requesting of the pubite-key-certlficate issuer 
authority 1 602 to issue a certificate of the registration 
authority 1 701 . In addition, the root registration authority 
1 601 and the public-key-certificate issuer authority 1 602 
execute cross certification processing. 
[0183] When certifteatlon is established in the cross 
certification processing, the root registration authority 

1 601 uses the private key of the root registration author- 
ity 1 601 to sign the identifier SPID of the registration au- 
thority 1 701 and the public key KpSp of the registration 
authority 1701 , generates EkssUSFID, KpSp'}sig.KsRoot- 
3p) by performing encryption using the session key gen- 
erated in the cross certification processing, and trans- 
mits the generated data to the publte-key-certificate is- 
suer authority 1602. 

[01 84] After decrypting the received data Eks2({SPID, 
KpSp'}sjg.KsRooisp)i and verifying the signature, the pub- 
lic-key-certificate issuer authority 1 602 perfonns validity 
checking on the public key KpSP of the registration au- 
thority 1701. The validity checking Is executed as 
processing in whbh, when the pubik; key and public key 
certificate of the same user are stored in the database 
described with reference to Fig. 5, they are invalidated 
and a newly updated public key is validated. The public- 
key-certificate issuer authority 1602 issues and regis- 
ters the newly updated public key certificate In the da- 
tabase. 

[0185] The public-key-certificate issuer authority 

1602 uses the private key KsIA of the public-key-certif- 
icate issuer authority 1 602 to sign the generated public 
key certificate, namely. IA«SP», genenates data 
({IA«SP»}sig.KsiA) by performing encryption using the 
session key Ks generated in the cross certification 
processing, and transmits the generated data to the root 



registration authority 1 601 . The root registration author- 
ity 1601 verifies the signature and uses its private key 
to sign the received data, and encrypts the signed data 
by using the session key (the session key generated in 

5 the cross certification processing executed between the 
registration authority 1701 and the root registration au- 
thority 1 601 ). The root registration authority 1 601 trans- 
mits the-generated data to the registration authority 
1 701 . After decrypting the received data using the ses- 

10 sion key, and verifying the signature, the registration au- 
thority 1701 stores the certifk^te. 
[0186] Similarty to Fig. 20, Fig. 21 is an Illustration of 
a procedure for issuing a new public key and private key 
certificate of a service provider as the registration au- 

15 thority 1 701 under management by the root registration 
authority 1 601 . However, In Rg. 21 , the new publte key 
and private key of the service provider are generated by 
the root registration authority 1601 . 
[0187] Fig. 21 differs from Fig. 20 in steps (2) to (6). 

20 These steps are described. The registration authority 
1701 and the root registration authority 1601 execute 
cross certifteation processing. This is perfomried using 
cross certiffcation keys (corresponding to the key Kab 
described with reference to Fig. 1 3) that are stored be- 

25 forehand in, for example, memories of the registration 
authority 1701 and the root registration authority 1601, 
or using the present publk: key and private key (see Fig. 
14). 

fp^ 88] Next, the registration authority 1 701 uses its pri- 

30 vate key K^p to sign the identifier SPID of the registration 
authority 1701, generates data EKs({SPID}sig.K8Sp) by 
performing encryption suing the session key Ks generat- 
ed in the cross certifrcation, and transmits the generated 
data to the root registration authority 1601. After using 

35 the session key Ks to decrypt the received data, and ver- 
ifying the signature, the root registration authority 1601 
recognizes the identifier SPID. Having recognized it, the 
root registration authority 1601 generates a new public 
key and private key of the root registration authority 1 601 . 

40 After that, the root registration authority 1 601 uses its pri- 
vate key to execute signing processing on the generated 
public key and private key of the registration authority 
1 701 , encrypts them using the session key, and transmits 
the encrypted keys to the registration authority 1 701 . The 

45 subsequent steps are similar to those in Fig. 20. 

[0189] Next, with reference to Fig. 22, revocation 
processing on a public key certifk:ate is described. Al- 
though Fig. 22 shows the revocation processing as 
processes among the user 2001, the root registration 

50 authority 1 601 , and the public-key-certificate Issuer au- 
thority 1 602, if there is the registration authority 1 701 
between the user 2001 and the root registration author- 
ity 1601 , the registration authority 1701 affects commu- 
nication between the user 2001 and the root registration 

55 authority 1601. 

[0190] The processing in Fig. 22 is described. The 
root registration authority 1601 perfonns processing for 
revocation when the public key of the user 2001 is, for 
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example, unlawfully distributed, or In accordance with a 
request from the user 2001 . This is executed as the 
process of adding the public-key infomiation of the user 
2001 to the revocation list described with reference to 
Figs. 9 and 10. The root registration authority 1601 per- 
forms registration to the revocation list, and requests the 
public-key-certlffcate issuer authority 1602 to perfomn 
invalidation of the public key certif cate. 
)191] First, the root registration authority 1601 and 
the public-key-certificate issuer authority 1602 execute 
cross certifteation processing. When certification is es- 
tablished, the root registration authority 1 601 uses the 
private key of the root registration authority 1 601 to sign 
the identifier SAMISD of the user 2001, which con^e- 
sponds to a revoked public key, and the public key 
KpUD. generates Eks((SAMID, KpUD}sig.KsRootSp) 
performing encryption using a session key generated In 
the cross certification, and transmits the generated data 
to the public-key^rtificate issuer authority 1602. 
[0192] After decrypting the received data Eks({SA- 
MID, KpUD}sig.K8Rootsp)> verifying the signature, 
the pubtic-key-certificate issuer authority 1 602 perfomns 
invalidation processing on the public key certificate cor- 
responding to the public key KpUD of the user 2001 . In 

other words, a flag in the jlgtg^t^d&fiy^®^"^^^ 
erence to Fig. 5 is set to indicate invalidation. The publk:- 
key-certificate issuer authority 1602 transmits, to the 
root registration authority 1601, data E|^({OK/ 
NG}3|g.KsiA) obtained such that a response that indi- 
cates whether the invalidation processing has been ex- 
ecuted (OK or NG) is signed and is encrypted using the 
ession key. 

[01 93] When the revocation processing on the public 
key certificate, which is consecutively performed, ends, 
the publte key of the user 2001 is not allowed to be used 
under a service managed by the root registration author- 
ity 1601 . In other words, transmission/reception and ver- 
ification of data encrypted using the publb key cannot 
be perfonned with the root registration authority 1601 , 
and also with another service provider managed by the 
root registration authority 1601, dealing using the re- 
voked public key is impossible. The root registration au- 
thority perfonns the differential distribution of the revo; 
cation list, as required. 
[0194] Fig. 23 illustrates the process of validating' a 
revoked public key and a revoked public key certificate. 
When a public key is revoked, the user 2001 is denied 
(NG) access to the root registration authority 1601. 
When the root registration authority 1601 validates the 
revocation of the revoked public key, the root registra- 
tion authority 1601 issues a certificate invalidating re- 
quest to the public-key-certif rcate issuer authority 1 602, 
and cross certification processing is executed between 
the root registratton authority 1601 and the publto-key- 
certifteate issuer authority 1602. 
[0195] When cross certifk^atlon is established, the 
root registration authority 1601 uses the private key of 
the root registration authority 1601 to sign the identifier 



SAiy^lSD of the user 2001, which corresponds to the 
public key to be validated, and the public key KpUD, 
generates Eks({SAMID, KpUD}sig.KsnooiSp) by perfomn- 
ing encryption using a session key generated in the 
cross certification, and transmits the generated data to 
the publc-key-certificate issuer authority 1 602. 
[0196] After decrypting the received data Ek5({SA- 
MID, KpUD}sig.KsR<^p), and verifying the signature, 
the public-key-certtftcate issuer authority 1 602 performs 
10 the processing of validating the revoked public key cer- 
---Ttif icate conresponding to the publk; key KpUD of the user 
. 'J 2001 . In other words, the flag in the database described 
with reference to Fig. 5 is set to indicate validation. The 
public-key-certifk»te issuer authority 1 602 also trans- 
is mits, to the root registration authority 1601, data Eks 
({0K/NG}3|g.|^iA) obtained such that a response that in- 
dbates whether the validation processing has been ex- 
ecuted (OK or NG) is signed and Is encrypted using the 
session key. The root registration authority performs the 
differential distribution of the revocation list, as required. 
[0197] When the validation processing on the publk: 
key certificate, whbh is consecutively performed, ends, 
the publk: key of the user 2001 is allowed to be used 
under the service managed by the root registration au- 
thority 1601. 

[0198] Rg. 24 is an illustration of the processing of 
deleting a public key certificate. In this case, the root 
registration authority 1 601 issues a certificate deleting 
request to the pubtic-key-certificate issuer authority 
to 1 602, and cross certif teation processing is executed be- 
tween the root registration authority 1 601 and the publte- 
m key-certificate issuer authority 1 602. 
^ [0199] When cross certification is established, the 
root registration authority 1601 uses the private key of 
!35 the root registratton authority 1 601 to sign the identifier 
SAMISD of the user 2001, whk^h corresponds to the 
public key to be deleted, and the public key KpUD, gen- 
erates Eks({SAMID, KpUD}sig.KsRootsp) by perfomriing 
encryption using a session key generated In the cross 
^ certification, and transmits the generated data to the 
public-key-certifteate issuer authority 1602. 
[0200] After decrypting the received data E)^({SA- 
MID, KpUD}sig.Kspooisp), and verifying the signature, 
the public-key-certifk:aite issuer authority 1 602 perfomns 
the processing of deleting the public key certificate cor- 
responding to the public key KpUD of the user 2001 . In 
other words, from the database described with refer- 
ence to Fig. 5, corresponding publb-key infomiation is 
deleted. The publk:-key-certificate issuer authority 1 602 
50 also transmits, to the root registration authority 1601, 
data EK3({0K/NG)sig.KsiA) obtained such that a re- 
sponse that indicates whether the deletion processing 
has been executed (OK or NG) is signed and is encrypt- 
ed using the session key. 
55 [0201] When the deletion processing on the pubtk: 
key certificate, which is consecutively perfonned, ends, 
the public key of the user 2001 Is not allowed to be used 
under the servbe managed by the root registration au- 
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thority 1601. 

[0202] Next, an example of construction is described 
in which the registration authority is set as a system 
holder in a hierarchical structure composed of the root 
registration authority and the registration authority. 
[0203] The system holder is formed by, for example, 
an authority that organizes and manages an Internet 
shop martcet on the Intemet, an authority that provides 
communication infrastructure for cellular phones, an au- 
thority that manages the use of cables for cable televi- 
sion, an electronic-money-card issuing body, orthe like. 
In other words, the system holder is defined as an au- 
thority that provides and manages an infrastructure for 
distributing contents or sen/ices which enables provi- 
sion of various contents and services and that manages 
devices. 

[0204] In Rg. 25 is shown an illustration of the rela- 
tionship among a system holder 2501 , a contents crea- 
tor 2502, a sen^ice provider 2503, and a user 2504, and 
In Fig. 26 are shown specific examples of the system 
holder, the contents creator, the service provider, and 
the user device. 

[0205] In Fig. 25, the system holder2501 provides an 
infrastructure for distributing contents and services that 
can be used in the contents creator 2502, the service 
provider 2503, and the user (device) 2504. The contents 
creator 2502 and the service provider 2503 provide con- 
tents or services by using the infrastructure provided by 
the system holder 2501 . The user (devlce)2504 re- 
ceives a service provided by the service provider 2503 
by using the infrastructure provided by the system hold- 
er 2501. 

[0206] In Fig. 26 are shown specific contents creator, 
service provider, and user device examples. As shown 
In Fig. 26, when the system holder is, for example, an 
Intemet-shop-marlcet organizer authority, the contents 
creator provides goods to be provided to the Intemet 
shop maricet. The service provider is a shop that sells 
the provided goods In the Intemet shop, and the user 
device is a PC or the lilce that uses the Intemet shop. 
[0207] When the system holder is an authority that 
provides a cellular-phone communication infrastructure, 
such as a communication company or the like, the con- 
tents creator uses the cellular-phone communication in- 
frastructure to make and produce providable contents 
and goods. The service provider uses the cellular-phone 
communication infrastructure to sell and provide the 
contents and goods provided by the contents creator to 
users. In this case, the user devk:e is a cellular phone. 
[0208] When the system holder Is an authority that 
provides a cable television communication infrastruc- 
ture, such as a cable-television-cabte-communication 
management company, the contents creator uses the 
cable-television communication infrastructure to make 
and produce providable contents and goods. Also pro- 
grams that are provided to the cable television are in- 
cluded in the contents. The service provider uses the 
cable-television communication infrastructure to sell 



and provide the contents and goods provided by the 
contents creator to the users, and is, for example, a ca- 
ble television company that directly collects audience 
charges from viewers. 
9 [0209] When the system holder is an authority that 
provides electronic money settlement Infrastructure, 
such as an electronk: money issuing authority, the con- 
tents creator is a content and goods providing authority 
that provides goods that can be used (purchased) by 
electronk: money, the service provider is a selling shop 
realized as a shop In which the contents and good pro- 
vided by the contents creator can be used using elec- 
tronic money. The user device is an IC card to whbh 
electron^ money is input, or the like. 
[0210] In addition, there are various types of system 
holders, and depending on the type of system holder, a 
contents creator, a servbe provider, and a user devk^ 
are formed. In other words, the system holder is defined 
as an authority that provides and manages a contents 
or service providing infrastructure enabling provision of 
contents and sen/lces usable by the user device. 
[0211] Here, a distribution construction is described, 
in which contents or services can be easily used for the 
users by controlling the system holder to implement the 
functions of the above-descn'bed registration authority. 
[0212] First, Fig. 27 is used to describe a public-key- 
cryptosystem distribution construction for contents or 
services in a form in which the system holder is not pro- 
vided with the functions of the registration authority. 
[0213] As shown in Fig. 27, various types of servtees 
that can be used by the users exit. Each of the types 
uses its unique publk; key encryption, i.e., the issuance 
of a unique public key certificate that is effective only in 
a particular servk:e by performing unique examination 
and unique registration, whereby the particular service 
is provided. Fig. 27 shows this conventional servbe pro- 
viding construction. In Fig. 27 are shown a group 2710 
that provides service A and a group 2720 that provides 
service B. 

[0214] The group 2710 that provides service A in- 
cludes a public-key-certificate issuer authority (lA-A) 
271 1 that is usable for providing service A, a service pro- 
vider 2714 that requests the use of a publto key certifi- 
cate, and a registration authority (RA-A) 2712 that exe- 
cutes the registration and management of a user (de- 
vk:e) 2715. Based on an examination by, for example, 
an offteiat examination authority 2713, the registration 
authority 2712 periomns, the registration of the servrce 
provider 271 4 and the user (device) 271 5, requests the 
publlc-key-certlfbate issuer authority (lA-A) 2711 to Is- 
sue a certificate, and perfomis the management of the 
service provider 2714 and the user (devbe) 2715. The 
public-key-certifk:ate issuer authority (lA-A) 2711 and 
the registration authority (RA-A) 2712 constitute a cer- 
tificate authority (CA-A). 

[0215] The group 2720 tiiat provides service B In- 
cludes a public-key-certificate issuer authority (lA-B) 
2721 that is usable for providing s'ervbe B, a servk^e pro- 
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vider 2724 that requests the use of a public key certifi- 
cate, and a registration authority (RA-B) 2722 that exe- 
cutes the registration and management of a user (de- 
vice) 2725. Based on an examination by, for example, 
an official examination authority 2723, the registration 
authority 2722 perfonms, the registration of the service 
provider 2724 and the user (device) 2725, requests the 
public-lcey-certificate issuer authority (lA-B) 2721 to is- 
sue a certificate, and performs the management of the 
service provider 2724 and the user (device) 2725. The 
public-lcey-certificate issuer authority (lA-B) 2721 and 
the registration authority (RA-B) 2722 constitute a cer- 
tificate authority (CA-B). 

[0216] When, in this construction, the user 2715, to 
which a public key certificate usable In service A is is- 
sued by perfonning registration via the registration au- 
thority (RA-A) 2712 in order to be provided with service 
A, receives a sen/ice in service B, the issued public key 
certificate cannot be used. In order that the user 2715 
may receive a s.ervk:e in servkre B, it is essential to per- 
form a new registration procedure using the registration 
authority (RA-B) 2722 so that a new public key certifi- 
cate is issued. 

[0217] To solve this point, it is possible that certif Ra- 
tion be perfonned by both the certificate authorities 
(CAs) that are each composed of the public-key-certifi- 
cate issuer authority and the registmtion authority 
shown in Fig. 27, or it is possible that the certificate au- 
thorities (CAs) be formed to have a hierarchy. However, 
this causes a defect in a processing load in the certifi- 
cate authority increases and in that the certificate au- 
thority structure becomes complex. Otherorise, when a 
construction is employed in which a plurality of public 
key certificates con^esponding to a plurality of services 
are stored in the devtee in order that the user may re- 
ceive the services, the storage area of the user device 
is much used to store the publk: key certificates. This 
construction causes a problem in a device having a lim- 
ited storage area, such as an IC card. 
[021 8] When both the user devtee 271 5 and the user 
device 2725 in Fig. 27 perfomri cross certification in of- 
fline, both have different certificate authorities that con- 
trol them, the cross certification cannot be executed, in 
order that cross certification may be effectively execut- 
ed, both a public key of a certificate authority that con- 
trols a device itself and a publk; key of a certifbate au- 
thority that controls an associated device must be stored 
in the devices, so that the number of pubic keys to be 
stored increases more when certifk:ation with various 
associated devices is required. 
[0219] In the construction in Fig. 27 that perfonns In- 
dependent management for each servce. various prob- 
lems occur. It is a construction shown In Fig. 28 in which 
each system holder is positioned at a hierarchy below 
each root registration authority that solves the problems. 
[0220] The construction in Fig. 28 is described. The 
construction in Fig. 28 corresponds to that in Fig. 27, 
and Includes a group of service providers in which the 



left one provides servtee A and the right one provkies 
service B. A service provider 2804 is a body providing 
service A, and a servk^e provider 2807 Is a body provid- 
ing servk^e B. 

5 [0221] The service provider 2804. a user (device) 
2805, the servk» provider 2807, and a user (device) 
2808 are subjects to be certificated, namely, bodies that 
execute data transmission and reception using public 
key encryption. Although Fig. 28 shows the construction 

10 conresponding to two servbes A and B, many servk:es 
can exist. 

[0222] The system holder A (2803) acts and functions 
as the above-described registration authority. The serv- 
k:e provider 2804 and the user (device) 2805 as subjects 

15 to be certifk^ted, which are under the control of the sys- 
tem holder A, request the system holder A (2803) to is- 
sue public key certificates. The system holder B (2806) 
receives public-key-certificate issuing requests from the 
service provider 2807 and the user (device) 2808. 

20 [0223] Each of the system holder A (2803) and the 
system holder B (2806) certificates subjects (entities 
participating in servkie, apparatuses) in each service. 
Each of the system holder A (2803) and the system hold- 
er B (2806) receives a public-key-certificate issuing re- 

25 quest about a publb (entity participating in servk^, ap- 
paratus) key used by a subject in each sen/Ice, and 
transfers it to a publb-key-certiftoate issuer authority 
2801 via a root registration authority 2802. The root reg- 
istration authority 2802 accepts publlc-key-certlftoate is- 

30 suing requests from the system holder A (2803) and the 
system holder B (2806), which are certificated. In other 
words, the root registration authority 2802 receives a 
public-key-certificate issuing request when the request 
is from the system holder A (2803) or the system hokjer 

35 B (2806), whteh is certificated by the root registration 
authority 2802. 

[0224] In Fig. 28, the servrce provider 2804 and the 
service provider 2807 are servk^e providers that execute 
provision of servce for distributing contents such as mu- 
40 sic data, Image data, and game programs, and are 
fonned by the servtee providing bodies for providing var- 
ious servbes, which have been described with refer- 
ence to Fig. 26. 

[0225] The system holder A (2803) and the system 
^ holder B (2806) are authorities that manage infrastruc- 
tures for realizing the servtees provided by the service 
provider 2804 and the servbe provider 2807, and are 
fomned by the cellular-phone-communication infrastruc- 
ture provider, the electronte-money/card Issuing author- 
50 ity, etc., whk:h have been described with reference to 
Fig. 26. 

[0226] This embodiment is characterized in that a sys- 
tem holder that provides or manages an infrastructure 
for realizing provision of contents and provision of serv- 
55 ices operates as an interagent in public-key-certificate 
certification and issuance of public key certif bates of a 
data-communication implementing sen^ice provider and 
user device, and performs management of registration. 
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Since the system holder is an authority that provides or 
manages an infrastructure for enabling provision of con- 
tents and provision of services, the system holder per- 
fomTs, in many cases, the management of users and 
service providers that use the infrastruc^re, and usually 
includes a management database. By using the man- 
agement database to also perform the management of 
publio-key-certificate receivers, efficient managennent 
of users or service providers can be executed. 
[0227] When a new communication infrastructure is 
constructed, and a new system holder appears, by set- 
ting the new system holder to be under the control of an 
existing root registration authority and public-key-certif- 
icate issuer authority, a public-key-certlficate issuing 
construction using the new infrastructure is easily real- 
ized, and provision of service using the new Infrastruc- 
ture is realized. 

[0228] The user device can be controlled to use vari- 
ous services such that one public key certificate is only 
stored in the user device. In other words, since in the 
construction in Fig. 28, one root registration authority 
and one public-key-certificate issuer authority are set to 
correspond to the system holders and the service pro- 
viders, the user device can use different services by re- 
taining one publk: key certificate. In addition, between 
user devtees which are underthe control of different sys- 
tem holders, cross certification can be performed using 
a public key issued by one common pubiic-key-certifi- 
cate issuer authority. 

[0229] Next, Rg. 29 is used to describe a specific con- 
struction for the use of a public key certificate in the pub- 
lb-key-certificate issuing system and data communca- 
tion method of the present invention. 
[0230] The construction in Fig. 29 includes a public- 
key-certificate issuer authority 2901 for perfonning pub- 
lic key management and public-key-certificate issu- 
ance, an entity, namely, a root registration authority 
2902 for performing recognition processing for a subject 
to be certificated that requests issuance of a public key 
and a public key certificate, a service provteler 2903 as 
a registration authority, a clearing center 2904, and a 
user terminal 2905. 

[0231] The registration authority 2902 is certifk^ted 
by the publk:-key-certificate issuer authority 2901 , and 
possesses a publk: key and private key of the root reg- 
istration authority 2902, and a public key certificate. A 
public key of the root registration authority 2902 and a 
public key of the public-key-certificate issuer authority 
2901 are posted to the service provider 2903 as a reg- 
istration authority which is under the control of the root 
registration authority 2902, the clearing center (payment 
RA) 2904, and the user terminal 2905, or are embedded 
in each apparatus. 

[0232] The service provider 2903 and the clearing 
center 2904 register identifiers in the root registration 
authority 2902, and obtain publb key certificates issued 
by the publlc-key-certifk>ate Issuer authority 2901 (proc- 
ess 2 shown). 



[0233] To recehre a servtee from the service provider 
2903, the user terminal 2905 registers an apparatus by 
transmitting a unit identifier to the registration authority 
as the service provider 2903 via an SAM (Secure Appli- 
5 cation Module) of the user terminal 2905 (process 3 
shown). 

[0234] After verifying whether a user temninal identi- 
fied for a sewlce provider (e.g., a service provider or 
shop not shown) by a unit identifier can use a service, 

10 the registration authority as the sen^ice provider 2903 
issues a publk: key certifteate via the publto-key-certlfi- 
cate issuer authority 2901. The user terminal 2905 
stores the issued public key certificate in the SAM of the 
user terminal (denoted by 4 shown). These processes 

f5 enable the usertenrtinal 2905 to perfomi publte-key da- 
ta communication in the system shown in Rg. 29 and to 
receive the provided servk:e. 

[0235] To receive a servbe from the clearing center 
(payment RA) 2904, the user terminal 2905 registers an 
20 apparatus by transmitting a unit identifier to the regis- 
tration authority as the servbe provider 2903 via the 
SAM (Secure Application Module) of the user tenminal 
2905 (process 6 shown). 

[0236] When executing payment processing on con- 
25 tents charges by means of the clearing center 2904, us- 
ing electrons money stored in the user terminal's SAM, 
the user terminal 2905 registers the identifier of the user 
terminal 2905 in the clearing center 2904. 
[0237] The clearing center 2904 perf omris credit con- 
30 trol , etc. , f or a settlement authority such as a bank, iden- 
tifies a user (payer), and issues a public key certificate 
via the root registration authority 2902 and the public- 
key-certiticate Issuer authority 2901 . The user terminal 
2905 stores the issued publk: key certificate in the user 
35 temiinars SAM (process 7 shown). 

[0238] When being provided with a sen^k:e managed 
by the sen^ice provider 2903, the usertemninal 2905 us- 
es the publk: key certificate received via the service pro- 
vider 2903. When using the servk:e of the clearing cent- 
re er 2904, or performs payment processing, the user ter- 
minal 2905 uses the publk: key certificate obtained by 
the clearing center 2904. 

[0239] When the clearing center 2904 needs to direct- 
ly use the public key certifk:ate transferred to the user 

^ terminal via the sendee provider 2903, the clearing cent- 
er 2904, public-key-certificate generating processing 
via the clearing center 2904 is not perfomned, and by 
performing processing in both the clearing center 2904 
and the root registration authority 2902, an already gen- 

50 erated public key certificate is used as an effective pub- 
lic key certificate for settlement by the clearing center 
2904. 

[0240] As described above, the present Invention has 
been fully described with reference to particular embod- 
55 iments. However, it is obvious that a person skilled in 
the art can modify or substitute the embodiments within 
the spirit of the present invention. In other words, the 
present Invention has been disclosed in the f omi of em- 
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